Task definition for specifying resource requirements

ABSTRACT

Task definitions are used by a task scheduler and prioritizer to allocate task operations to a plurality of processing units. The task definition is an electronic record that specifies resources needed by, and other characteristics of, a task to be executed. Resources include types of processing nodes desired to execute the task, needed amount or rate of processing cycles, amount of memory capacity, number of registers, input/output ports, buffer sizes, etc. Characteristics of a task in clued maximum latency time, frequency of execution of a task, communication ports, and other characteristics. An examplary task definition language and syntax is described that uses constructs including order of attempted scheduling operations, percentage or amount of resources desired by different operations, handling of multiple executable images or modules, overlays, port aliases and other features.

CROSS-REFERENCES TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.10/233,175 filed on Aug. 29, 2002, of which the entire disclosure isincorporated herein by reference.

BACKGROUND OF THE INVENTION

This application is generally related to digital processing systems, andmore specifically to digital processing systems having multipleprocessing nodes.

In configurable systems, it is typically desirable to be able to executemultiple tasks concurrently. If some or all of these tasks have timingconstraints (for example, if “real-time” operation is desired), theconfigurability of the system may be limited. This can be explained withreference to typical methodologies used to implement real-time systems.

Early real-time systems were often “hand crafted” in order to meetstringent timing constraints. In particular, real-time tasks that wereto be executed concurrently were analyzed to determine their detailedtiming requirements. Then, a real-time operating system was “builtaround” these tasks such that their timing, requirements were satisfied.Because such real-time systems are tied so closely with the underlyingtasks, they are not easily modifiable or extendible. For example,attempting to modify a task or add an additional task to the systemcould require a complete re-design of the system.

In order to make such systems “configurable,” the possibleconfigurations are typically first determined and fixed, and then thesystem is designed to accommodate the timing constraints of the variouspossible configurations. If it is desired to add a new configuration orfeature, detailed knowledge of the entire system, including knowledge oftasks that might be executed at any particular time, is typicallyrequired in order to ensure that the system can execute tasks in“real-time” under the various configurations. Alternatively, the entiresystem might need to be re-designed. Thus, the design of the system, andthat of individual tasks that are to be executed, is typically tightlycontrolled. This can make it difficult to add new configurations to adevice, and/or to permit third-parties to develop configurations for thedevice.

A more flexible approach to real-time systems is often referred to asthe “scheduled reservation model.” Under the scheduled reservationmodel, the processor is viewed as a quantifiable resource that can bereserved like physical memory or disk blocks. But if two tasks requireprocessor resources simultaneously, then one of the tasks will have towait until the other is finished. If this task must wait too long, thenit may not be able to execute in “real-time.” Thus, the scheduledreservation model cannot guarantee real-time execution of all tasks.

The scheduled reservation model provides a more flexible approach todesign of real-time systems. In particular, design of a task or tasksdoes not require detailed knowledge of the entire system and/or othertasks. Thus, unlike “hand-crafted” real-time systems, task design neednot be tightly controlled, and new configurations and/or features can bedeveloped by those (e.g., third parties, etc.) without detailedknowledge of the system or of other tasks that may run on the system.For example, new features could be developed for a configurable devicewithout requiring any changes to the underlying system or with othertasks previously designed for the system. Further, such features couldbe developed by third-parties with limited knowledge of the underlyingsystem and/or of other features. As discussed above, however,“real-time” operation might not be guaranteed.

Another approach to real-time systems is often referred to as the “fixedpriority model.” Under the fixed priority model, each task is assigned apriority level by developers. During operation, tasks are executedstrictly based on their priority level. For example, a task with ahigher priority than that of an executing task can interrupt that task,whereas a task with a lower priority than that of the executing taskmust wait until the executing task finishes. As with the scheduledreservation model, the fixed priority model cannot guarantee real-timeexecution of tasks (except for the highest priority task).

As with the scheduled reservation model, the fixed priority modelprovides a more flexible approach to design of real-time systems. Inparticular, design of a task or tasks does not require detailedknowledge of the entire system and/or other tasks. It does, however,require some knowledge of its priority vis-à-vis other tasks that may beexecuted by the system. Thus, task design need not be tightlycontrolled, but does usually require some degree of coordination. Thus,similar to systems employing a scheduled reservation model, new featuresfor could be developed for a configurable device without requiringsignificant changes to the underlying system or with other taskspreviously designed for the system. It may, however, require areconfiguration of priorities of tasks that can be implemented on thedevice. Additionally, such features could be developed by third-partieswith limited knowledge of the underlying system and/or of otherfeatures. But, “real-time” operation cannot be guaranteed.

Configurable systems having multiple processing nodes generallyexacerbate the above-mentioned shortcomings and introduce others. It isdesirable to provide techniques for use in configurable systems havingmultiple processing nodes that improve upon one or more of theabove-mentioned (or other) shortcomings in the prior art.

BRIEF SUMMARY OF THE INVENTION

Task definitions are used by a task scheduler and prioritizer toallocate task operations to a plurality of processing units. The taskdefinition is an electronic record that specifies resources needed by,and other characteristics of, a task to be executed. Resources includetypes of processing nodes desired to execute the task, needed amount orrate of processing cycles, amount of memory capacity, number ofregisters, input/output ports, buffer sizes, etc. Characteristics of atask include maximum latency time, frequency of execution of a task,communication ports, and other characteristics.

An examplary task definition language and syntax is described that usesconstructs including order of attempted scheduling operations,percentage or amount of resources desired by different operations,handling of multiple executable images or modules, overlays, portaliases and other features.

In one embodiment the invention provides a computer program productcomprising a computer readable storage structure embodying computerreadable code therein, the computer readable code comprising a taskdefinition code that specifies requirements of a task adapted to beexecuted on a configurable device having a plurality of processingnodes, the task definition code including code that indicates processingnode resources required by the task.

In another embodiment the invention provides a computer data signalembodied in a carrier wave, the computer data signal comprising a taskdefinition code that specifies requirements of a task adapted to beexecuted on a configurable device having a plurality of processingnodes, the task definition code including code that indicates processingnode resources required by the task.

In another embodiment the invention provides a configurable devicecomprising a plurality of processing nodes; a scheduler, coupled to theplurality of processing nodes, that assigns tasks to the processingnodes for execution; and a memory, coupled to the scheduler, the memoryincluding a task definition code that specifies requirements of at leastone task adapted to be executed by the configurable device, the taskdefinition code having code that indicates processing node resourcesrequired by the task.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram illustrating an example of a systemthat can use embodiments of the present invention;

FIG. 2 is a simplified block diagram of an example of a device that canimplement tasks that have been defined according to embodiments of thepresent invention; and

FIG. 3 is a simplified diagram illustrating a linking of ports andmodules as specified by a task definition.

DETAILED DESCRIPTION OF THE INVENTION Overview

Embodiments according to the present invention provide techniques fordefining tasks to be implemented on a configurable device. In somespecific embodiments, the target device includes a plurality ofprocessing nodes on which tasks can be executed. In these embodiments,processing nodes can include one or more of common types of processingresources such as general purpose processors, general purpose digitalsignal processors, special purpose processors, finite-state machines(FSMs), application-specific integrated circuits (ASICs), etc.

FIG. 1 is a simplified block diagram illustrating an example of a systemthat uses embodiments of the present invention. The system 100 includesa plurality of processing nodes 105 a, 105 b, 105 c, 105 d, . . . , anda scheduler 110. Scheduler 110 determines which of tasks 115 a, 115 b,115 c, 115 d, . . . are to be carried out on which of the nodes 105 a,105 b, 105 c, 105 d, . . . . For example, as illustrated in FIG. 1,scheduler 110 has assigned tasks A and D for execution on node 1, andhas assigned tasks B and C for execution on node 4.

Associated with each of tasks 115 a, 115 b, 115 c, 115 d, is acorresponding task definition (120 a, 120 b, 120 c, 120 d, . . . ). Asis described subsequently, task definitions 120 a, 120 b, 120 c, 120 d,. . . provide information about their associated tasks. Such informationcan include a type of processing node required (or merely desired) toexecute the task, required (or desired) processing resources, otherrequired (or desired) resources (e.g., memory, buffers, ports, etc.),information for communicating with the task, etc.

Scheduler 110 can use information provided by task definitions 120 a,120 b, 120 c, 120 d, . . . in order to assign tasks 115 a, 115 b, 115 c,115 d to processing nodes 105 a, 105 b, 105 c, 105 d, . . . forexecution in an attempt to satisfy the requirements of the tasks spelledout in the task definitions.

U.S. patent application Ser. No. 10/189,791 (Attorney Docket No.021202-002400US), to Paul L. Spoltore, et al., entitled “Method andSystem for Real-Time Multitasking,” filed Jul. 3, 2002 (hereinafter“Spoltore et al.”), which is herein incorporated by reference in itsentirety for all purposes, describes techniques for assigning tasks toprocessing nodes for execution. In a specific embodiment, scheduler 110can use one or more of the techniques described in Spoltore et al. toassign 115 a, 115 b, 115 c, 115 d to processing nodes 105 a, 105 b, 105c, 105 d, . . . for execution.

A Configurable Device

FIG. 2 is a simplified block diagram of an example of a device 150 thatcan implement tasks that have been defined according to embodiments ofthe present invention. It should be apparent, however, that aspects ofthe apparatus and methods described herein can be applied to manydifferent types of computing architectures including, for example,general purpose processors, digital signal processors, custom integratedcircuits, discrete circuits, etc. Additionally, aspects of the apparatusand methods described herein can be applied, in general, to any type ofprocessing approach including, parallel processing, distributedprocessing, synchronous processing, asynchronous processing, etc.

Device 150 can be, for example, a consumer electronics device (or acomponent thereof) such as a cell phone, pager, personal digitalassistant (PDA), global positioning system (GPS) receiver, etc. Itshould be apparent, however, that device 150 can be any type of devicethat can benefit from a processing engine.

Device 150 includes input/output (I/O) system 152 for providing dataexchange with the external environment (illustrated at 170), connectionto peripherals 174, and interaction with a human user via user interface172. Data exchange includes exchanges with digital networks such as aninternet, the Internet, an intranet, an extranet, communicationinfrastructures such as a telephone network, radio frequency exchangesas to wireless networks, etc. Any type of physical communication or datatransfer network can be employed. Any type of protocol can be used toperform the communication.

User interface 172 allows a human user to operate the device, and toperform other functions. Typically, a user interface includes a displayscreen and manual controls such as buttons, a pointing device (e.g., amouse, trackball, touchpad, etc.), knobs, switches, and other types ofcontrols. Additional output devices can include speakers, forcefeedback, etc. Peripherals 174 include storage devices such as diskdrives, input/output devices such as keyboards, monitors, etc.

I/O system 152 can be in communication with different systems in device150. For example, FIG. 2 shows I/O system 152 communicating with taskdefinition store 154 and storage and processing resources 160. Otherarrangements are possible.

Task definition store 154 is used to store programs, adaptation orconfiguration information, or other information used to control ormanage the processing or functioning of device 150. In one embodiment,adaptation information is used to define tasks that are executed bysystems within device 150 to achieve functionality. For example, one ormore tasks might allow device 150 to communicate using time-divisionmultiplexed access (TDMA) with a cellular phone network. One or moreother tasks could provide a user with a phone directory including aninterface for creating, modifying, organizing, searching, etc., thedirectory. Yet other tasks can implement a time-of-day clock, Internetweb browsing, GPS position indication, calculator, email interface, etc.In general, any type of functionality can bc implemented by a task.Combinations of functionality can bc provided by one or more tasks.Further, a task may implement only a portion of a feature, function, orother process or functionality.

Scheduler 156 causes tasks, or portions of tasks, from task definitionstore 154 to be executed. Scheduler 156 can, optionally, use informationprovided by prioritizer 158 in determining how to specify the use ofresources 160 to be used to execute a task. For example, scheduler 156can assign all resources to a task that has been given a high priorityby prioritizer 158. Conversely, scheduler 156 may reduce resourcesallocated to a task, or suspend execution of a task, if the task has alow priority.

Resources 160 include storage 162 and processing resources 164. Storage162 can be, for example, system memory in the form of random-accessmemory (RAM), or other forms of storage. Storage 162 can be distributedthroughout the processing elements, it can be centralized, or it can bea combination of centralized and distributed storage. Processingresources 164 can include one or more of common types of processingresources such as general purpose processors, FSMs, ASICs, etc. In oneembodiment, processing resources 164 include multiple processing nodes168 according to the adaptive computing engine (“ACE”) architecture asdescribed in U.S. patent application Ser. No. 09/815,122, entitled“Adaptive Integrated Circuitry With Heterogeneous And ReconfigurableMatrices Of Diverse And Adaptive Computational Units Having Fixed,Application Specific Computational Elements,” filed Mar. 22, 2001(“Masters”). In this embodiment, each node can be of a specific type,such as math, bit/logical, FSM, reduced-instruction set computing(RISC), etc. In this embodiment, nodes are interconnected and may haveassociated resources, such as memory. A detailed description of the ACEarchitecture is provided in Masters, which is herein incorporated byreference in its entirety for all purposes. In other embodiments, all ofthe nodes may be general purpose or of one type.

Task Definition

Embodiments of task definitions according to the present invention willnow be described. In these embodiments, a task is comprised of one ormore modules, and the requirements of each module can be specified inthe task definition. It is to be understood, however, that it is not arequirement that tasks be defined in terms of modules. This is merely anexample of one implementation, and one skilled in the art will recognizemany modifications, equivalents, and alternatives. For example, in otherembodiments, a task may not be specified in terms of modules that makeup the task. In still other embodiments, a task may comprise one or moremodules, where each module may in turn be comprised of one or moresub-modules. In these embodiments, a task may be specified in terms ofsub-modules.

Referring to FIG. 2, in embodiments to be used with systems such asdevice 150, task definitions may be stored in task definition store 154.In these embodiments, tasks and task definitions can be, for example,downloaded by device 150 from a remote location. For instance, with adevice 150 that includes, or is coupled with, a modem, networkinterface, etc., a task definition could be transmitted to device 150via a computer data signal embodied on a carrier wave, over a networksuch as the Internet, etc., and then loaded into task definition store54. Similarly, a task definition could be transmitted to a computer, andthen downloaded from the computer to task definition store 154 via, forexample, a serial port, parallel port, etc. In other embodiments inwhich device 150 includes, or is coupled with, a floppy disk drive,memory card reader, etc., task definitions could be loaded into taskdefinition store 154 via a computer readable medium such as a disk,memory card, etc.

As described above, task definitions are associated with the tasks ofwhich they provide information. In some embodiments, task definition mayinclude a link, pointer, etc., to the task to which it is associated, ora location of the task in a memory, etc. In other embodiments, the taskdefinition may be included with the task itself. For example, a taskdefinition may be within a same file as the task itself, appended to thefile, etc.

The type of information provided by task definitions will now bedescribed. Some of this information can be used, for example, byscheduler 110 of FIG. 1, scheduler 156 of FIG. 2, an operating system,etc., to determine to which processing nodes tasks should be assigned orloaded, by which processing nodes tasks should be executed, etc.Additionally, some of this information can be used by an operatingsystem, other tasks, etc., to communicate with, provide information to,etc., a task.

A. Processing Node Resources

In some embodiments, a task definition may specify resources of aprocessing node that are required (or desired) by the associated task.The resources could be specified, for example, in terms of a percentageof the processing node's processing power. Examples of source code forspecifying processing node resources is provided subsequently.

The time between when a task can begin to execute (e.g., when databecomes available, a trigger occurs, etc.) and when the task actuallybegins to execute will be referred to herein as “latency.” For sometasks, it may be desired that the latency not exceed (or onlyoccasionally exceed) some maximum amount (herein referred to as the“maximum allowable latency”). Thus, in some embodiments, specifyingresource requirements of a task can include specifying a maximumallowable latency. A maximum allowable latency could be specified, forexample, in units of time, clock cycles, etc.

In some embodiments, specifying resource requirements of a task caninclude specifying a minimum amount of time required to execute thetask. Time required could be specified, for example, in units of time,clock cycles, etc.

In some embodiments, specifying resource requirements of a task caninclude specifying a minimum frequency of execution of the task. Thefrequency of execution could be specified, for example, in units of time(period), clock cycles (period), hertz (frequency), etc.

Spoltore et al. describes various types of resource requirements that,in some embodiments, can be included in task definitions.

B. Processing Node Type

In some embodiments in which a device on which the task can be executedincludes processing nodes of different types, a task definition mayspecify the type of a processing node required (or desired) by theassociated task. For example, as described with respect to FIG. 2,device 150 can include one or more of common types of processingresources such as general purpose processors, FSMs, ASICs, etc. In onespecific embodiment, device 150 includes multiple processing nodesaccording to the ACE architecture as described in Masters. In thisembodiment, each node is of a specific type, such as math, bit/logical,FSM, or reduced-instruction set computing (RISC).

In some embodiments, a preferred choice of processing node type can bespecified, as well as one or more back-up choices. In these embodiments,if the preferred type of processing node is unavailable, the task can beassigned to a processing node of one of the back up choice types.

C. Other Resources

In some embodiments, a task definition may specify other types ofrequired (or desired) resources. For example, a task definition mayspecify memory requirements, such as a minimum amount of memory, amaximum amount of memory, a type of memory, etc. Also for example, atask definition may specify input/output (I/O) requirements such asbuffer requirements, I/O port requirements, etc. In some embodiments,I/O requirements can be specified, for example, in terms of a minimumbuffer size, a maximum buffer size, a minimum throughput, a maximumthroughput, a type of input, output, or I/O port, a specific input,output, or I/O port, etc. Examples of source code for specifyingrequirements of buffers will be described subsequently.

D. Port Aliases

In some embodiments, a task definition can include port aliases used forcommunicating between tasks, within a task, between a task and theoperating system, etc. Ports can be, for example, I/O ports, registers,memories, sections of memories, etc., used for providing information to,or receiving information from, tasks. For instance, a task definitioncan include global alias names of ports for communicating with the task.Examples of source code for specifying port aliases will be describedsubsequently.

E. Task Loading

In some embodiments, a task definition can include requirements forloading the task. For example, a task definition can specify whether thetask should be loaded for execution on a particular node, or within aparticular group of nodes. Additionally, in some embodiments, a taskdefinition can specify whether a task should be loaded for execution ona node on which another particular task or tasks is loaded forexecution, or near a node or nodes on which another particular task ortasks is loaded for execution.

As described above, in some embodiments a task may comprise one or moremodules. In these embodiments, a task definition can specifyrequirements relating to the node or nodes on which the modules shouldbe loaded for execution. For instance, a task definition can specifythat a particular module be loaded on a particular node or within agroup of nodes. Also, a task definition can specify that two or moreparticular modules be loaded on a same node, or within one group ofnodes. Similarly, a task definition can specify that two or moreparticular modules be loaded on different nodes, or on different groupsof nodes. In some embodiments, a task definition can specify loadingrequirements for some modules while not specifying such requirements forother modules.

Examples

Examples of source code for implementing task definitions will now bedescribed. It is to be understood that these examples are merelyillustrative and are not limiting.

A. Module Definition

In some embodiments in which a task can comprise one or more modules, atask definition includes a module definition section. An example ofsource code included within a module definition section is providedbelow. In this example, a module definition section begins with a nameindicating the module to be defined, followed by parentheses andbrackets:

modSample(“modSample_EntryPoint”, “m_node_files/modSample.mlf”) {   .  .   . }

In the above example, a filename of an executable image of the moduleand an entry point within the file are specified within the parentheses.In particular, the filename of an executable images is “modSample.mlf”located in the directory “m_node_files.” Additionally, the entry pointis “modSample_EntryPoint.” Within the brackets, other requirements ofthe module can be specified.required, as will be described subsequently.

In some embodiments, multiple file names can be specified, correspondingto alternative executable images of the module. For example, ifdifferent types of nodes require different formats, different code,etc., then one or more alternative executable images can be specified incase a particular node type is unavailable, for example, because thedevice on which the module is to be executed does not include it,because all nodes of this type have already been reserved by othermodules, etc. In the following example, it is assumed that a device onwhich the module could be loaded might include two types of processingnodes: m-type nodes and a-type nodes. A required (or desired) type ofnode for a particular node can be specified by the filename extension ofthe executable image of the module. In this particular example, a “.mlf”extension indicates, for example, to an operating system, to ascheduler, etc., that the module should be loaded to an m-type node,whereas a “.alf” extension indicates that the module should be loaded toan a-type node:

modSample(“modSample_EntryPoint”, “m_node_files/modSample.mlf”,  “a_node_files/modSample.alf”) {   .   .   . }

In the above example, the task definition specifies that the operatingsystem, scheduler, etc., should first attempt to load the file named“modSample.mlf” to an m-type node (or, alternatively, to a node thatsupports an m-type format). If there is no such processing nodeavailable, then it should be attempted to load the file named“modSample.alf” to an appropriate processing node.

In some embodiments, multiple instances of a module can be loaded andexecuted.

An example of source code included within a module definition sectionthat defines multiple images of a module is provided below. In thisexample, two instances are defined which reference the same executableimage “modSample.mlf”:

modSample1(“modSample_EntryPoint”, “m_node_files/modSample.mlf”) {   .  .   . } modSample2(“modSample_EntryPoint”,“m_node_files/modSample.mlf”) {   .   .   . }

B. Module Resources Definition

The source code examples below illustrate one specific embodiment of atask definition that specifies node resources for a module. A keyword“cpu” followed by a number between 0 and 100 (inclusive) is used tospecify a percentage of required processing resources of a node. In thefollowing example, required processing node resources for the modulewhose executable image is included in the file “modSample.mlf” arespecified. In particular, this module requires 25% of the processingnode's processing power:

modSample(“modSample_EntryPoint”, “m_node_files/modSample.mlf”) {   .  .   .   resource( ) {     .     .     .     cpu 25     .     .     .  }   .   .   . }

The granularity of the number specifying processing power can vary withdifferent implementations, different devices on which the module is tobe executed, different types of processing nodes, etc. For example, thegranularity can be in units of 1, 5, 10, 25, etc. If desired, a smallergranularity can also be used.

If multiple executable images of a module are defined, requiredprocessing resources can be specified as the same for both images, orspecified individually. In the following example, required processingresources for two executable images of a module(“m_node_files/modSample.mlf” and “a_node_files/modSample.alf”) arespecified as having the same resource requirement:

modSample(“modSample_EntryPoint”, “m_node_files/modSample.mlf”,  “a_node_files/modSample.alf”) {   .   .   .   resource( ) {     .    .     .     cpu 25     .     .     .   }   .   .   . }

In the following example, required processing resources for twoexecutable images of a module (“m_node_files/modSample.mlf” and“anode_files/modSample.alf”) are specified as having the differentresource requirement:

modSample(“modSample_EntryPoint”, “m_node_files/modSample.mlf”,  “a_node_files/modSample.alf”) {   .   .   .  resource(“m_node_files/modSample.mlf”) {     .     .     .     cpu 75    .     .     .   }   resource(“a_node_files/modSample.alf”) {     .    .     .     cpu 25     .     .     .   }   .   .   . }

C. Module Overlay Definition

In some embodiments, use of overlays is permitted. A source code exampleof a task definition that specifies overlay requirements is providedbelow. In this example, the keyword “overlays” is used followed byparentheses and brackets. The parentheses can be used to specify aparticular executable image of a module. If only one executable imagehas been defined, or if the overlays are the same for the differentexecutable images, the parentheses can be left empty. Within thebrackets, the entry points and files of one or more overlays can bespecified:

modSample(“modSample_EntryPoint”, “m_node_files/modSample.mlf”) {   .  .   .   overlays( ) {     “Overlay_EntryPoint”,“m_node_files/modOverlay1.mlf”     “Overlay_EntryPoint”,“m_node_files/modOverlay2.mlf”     “Overlay_EntryPoint”,“m_node_files/modOverlay3.mlf”   }   .   .   . }

In the above example, three overlays are defined. This information canbe used, for example, to ensure that enough memory is reserved for themodule when it is loaded. For instance, in the above example, anoperating system could reserve an amount of memory greater than or equalto the size of the executable image “modSample.mlf” plus the size of thelargest of the three overlay files.

D. Port Aliases

In some embodiments, a task definition includes a port alias section. Anexample of source code that illustrates port aliases is provided below.In this example, a alias section is followed by a module definitionsection:

inBuf_public 0 outBuf_public 0 . . . modSample(“modSample_EntryPoint”,“m_node_files/modSample.mlf”) {   inBuf_private inBuf_public  outBuf_private outBuf_public   .   .   . }

In the above example, two global aliases are defined: “inBuf_public” and“outBu_fpublic.” These aliases identify ports that can be used tocommunicate with the module “modSample.” The “0” following each of theseport aliases specify that the ports requirements are default values.Source code examples of specifying requirments of ports will bedescribed subsequently.

Within the module definition section, the global alias names are linkedto internal port names of the module: “inBuf_private” and“outBuf_private.” This can be useful, for example, when multipleinstances of the same module are to be loaded. And example of using portaliases with multiple module instances is provided below:

inBuf_public 0 xfrBuf_public 0 outBuf_public 0 . . .modSample1(“modSample_EntryPoint”, “m_node_files/modSample.mlf”) {  inBuf_private inBuf_public   outBuf_private xfrBuf_public   .   .   .} modSample2(“modSample_EntryPoint”, “m_node_files/modSample.mlf”) {  inBuf_private xfrBuf_public   outBuf_private outBuf_public   .   .   .}

In the above example, two instances of the same module are to be loaded,and three global aliases are defined. The private aliases of the twomodule instances are linked with the public aliases such that the portswill be interfaced as shown in FIG. 3.

E. Port Resource Definition

As described above, in some embodiments, a task definition may specifyinput/output (I/O) requirements such as buffer requirements, I/O portrequirements, etc. Examples of source code for specifying requirementsof buffers are provided below. In the following example, requirements oftwo ports are specified:

inBuf_public 512 outBuf_public 256, 64, 4, 2046 . . .modSample(“modSample_EntryPoint”, “m_node_files/modSample.mlf”) {  inBuf_private inBuf_public   outBuf_private outBuf_public   .   .   .}

In the above example, the port “inBuf_public” is specified to include512 words of memory. The port “outBuf_public” is specified to include256 words of memory, comprised of 4 separate buffers, each having 64words. Additionally, the port “outBuf_public” is specified to be capableof handling a sustained data rate of at least 2046 kilobits of data persecond. Any appropriate word size can be used depending upon theparticular implementation (e.g., 8-bits, 16-bits, 32-bits, etc.).Additionally, port requirements need not be specified in terms of words.For example, port requirements could be specified in terms of bits,fixed-size blocks of words, etc. Similarly, a particular representationof a specified data rate is not required. In the following example,three ports are defined, each specifying an equivalent minimum data rateusing different representations:

oneBuf_public 256, 64, 4, 2097152 twoBuf_public 256, 64, 4, 2048KthreeBuf_public 256, 64, 4, 2M . . .

F. Module Loading

As described above, in some embodiments, a task definition can specifyrequirements for loading the task. A source code example is providedbelow that specifies loading requirements for a plurality of modulesthat comprise a task. In a specific embodiment, the tasks are to beloaded on a device that includes a group of processing nodes referred toas “ACM.” Additionally, within the “ACM” processing nodes are organizedinto groups of four nodes, referred to as “quads.” In the example below,loading requirements of 5 different modules (“modSample1,” “modSample2,”“modSample3,” “modSample4,” “modSample5”) are specified:

ACM( ) {   modSample1   Quad( ) {     modSample2     Node( ) {      modSample3       modSample4     }     Node( ) {       modSample5    }   } }

In the above example, because modules “modSample1,” “modSample2,”“modSample3,” “modSample4,” and “modSample5” are included within the“ACM” brackets, these modules should be loaded onto the ACM group ofprocessing nodes. Additionally, because module “modSample1” is notincluded within “Quad” or “Node” keyword brackets, then this module canbe loaded on any “Quad” or “Node” in the “ACM” group, and without regardto any of the other modules.

Modules “modSample2,” “modSample3,” “modSample4,” and “modSample5” areincluded within brackets of a “Quad” keyword. This specifies that“modSample2,” “modSample3,” “modSample4,” and “modSample5” should beloaded on the same “Quad.” Module “modSample2” is not included within“Node” keyword brackets. This specifies that this module can be loadedon any “Node” in the “Quad,” and without regard to any of the othermodules. Modules “modSample3” and “modSample4” are included within oneset of “Node” keyword brackets, and module “modSample5” is includedwithin another set of “Node” keyword brackets. This specifies thatmodules “modSample3” and “modSample4” should be loaded on the sameprocessing node, and that module “modSample5” should be loaded on adifferent processing node than that of modules “modSample3” and“modSample4.”

G. Example of a Task Definition

An example of a task definition is provided below. This example includesthree sections: a “Port Aliases” section, a “Module Definition” section,and a “Module Loading” section:

//-----------------------------------------------------------------------------------------// Section 1 - Port Aliases inHostFifo 0x040 scatterBuf0 0x100scatterBuf1 0x100 scatterBuf2 0x100 gatherBuf0 0x100 gatherBuf1 0x100gatherBuf2 0x100 outHostFifo 0x400 tag0 0 tag1 0 tag2 0 ctlBuf 0//-----------------------------------------------------------------------------------------// Section 2 - Module Definitions modInput(“modInput_EntryPoint”,“modGenData/modGenData.alf”) {   inBuf inHostFifo   outBuf genData  ctlBuf SelectWhich   resource(“modGenData/modGenData.alf”) {     cpu25   } } modScatter(“modScatter_EntryPoint”,“modScatter/modScatter.alf”,                ,“modScatter/modScatter.mlf”) {   inBuf outBuf   outBuf0 scatterBuf0  outBuf1 scatterBuf1   outBuf2 scatterBuf2  resource(“modScatter/modScatter.alf”) {     cpu 25   }  resource(“modScatter/modScatter.mlf”) {     cpu 100   } }modDecompress1(“modDecompress_EntryPoint”,“modDecompress/modDecompress.mlf”, “modDecompress/modDecompress.alf”) {  inBuf scatterBuf0   outBuf gatherBuf0   tag tag0  resource(“modDecompress/modDecompress.mlf”) {     cpu 25   }  resource(“modDecompress/modDecompress.alf”) {     cpu 100   } }modDecompress2(“modDecompress_EntryPoint”,“modDecompress/modDecompress.mlf”) {   inBuf scatterBuf1   outBufgatherBuf1   tag tag1   resource( ) {     cpu 25   } }modDecompress3(“modDecompress_EntryPoint”,“modDecompress/modDecompress.mlf”) {   inBuf scatterBuf2   outBufgatherBuf2   tag tag2   resource( ) {     cpu 25   } }modGather(“modGather_EntryPoint”, “modGather/modScatter.alf”) {   inBuf0gatherBuf0   inBuf1 gatherBuf1   inBuf2 gatherBuf2   outBuf outHostFifo  resource( ) {     cpu 25   }   overlays( ) {     “EntryPoint”,“modGather/overlay1.alf”     “EntryPoint”, “modGather/overlay2.alf”   }}//-----------------------------------------------------------------------------------------// Section 3 - Module Loading ACM( ) {   modInput   Quad( ) {    modGather     modDecompress3     Node( ) { modScatter     }    Node( ) { modDecompress1     }     Node( ) { modDecompress2     }  } }

While the above is a full description of the specific embodiments,various modifications, alternative constructions, and equivalents may beused. Therefore, the above description and illustrations should not betaken as limiting the scope of the present invention which is defined bythe appended claims.

1. A computer program product comprising a computer readable storagestructure embodying computer readable code therein, the computerreadable code comprising: a task definition code that specifiesrequirements of a task adapted to be executed on a configurable devicehaving a plurality of processing nodes, the task definition codeincluding: code that indicates processing node resources required by thetask.
 2. The computer program product of claim 1, wherein the code thatindicates processing node resources required by the task includes codethat indicates processing power required of at least one processingnode.
 3. The computer program product of claim 1, wherein the code thatindicates processing node resources required by the task includes codethat indicates a required execution time of at least a portion of thetask.
 4. The computer program product of claim 1, wherein the code thatindicates processing node resources required by the task includes codethat indicates a maximum allowable latency of at least a portion of thetask.
 5. The computer program product of claim 1, wherein the code thatindicates processing node resources required by the task includes codethat indicates a frequency of execution of at least a portion of thetask.
 6. The computer program product of claim 1, wherein the taskcomprises one or more modules, and wherein code that indicatesprocessing node resources required by the task includes code thatindicates processing node resources required by at least one of themodules.
 7. The computer program product of claim 1, wherein the taskdefinition code further includes code that indicates one or more typesof processing nodes required to execute at least a portion of the task.8. The computer program product of claim 1, wherein the task definitioncode further includes code that indicates one or more processing nodesrequired to execute at least a portion of the task.
 9. The computerprogram product of claim 1, wherein the task definition code furtherincludes code that indicates memory requirements of at least a portionof the task.
 10. The computer program product of claim 1, wherein thetask definition code further includes code that indicates portrequirements of at least a portion of the task.
 11. The computer programproduct of claim 1, wherein the task definition code further includescode that indicates port aliases.
 12. The computer program product ofclaim 1, wherein the task definition code further includes code thatindicates requirements for loading of at least a portion of the taskonto one or more processing nodes.
 13. The computer program product ofclaim 12, wherein the task comprises a plurality of modules, and whereinthe code that indicates requirements for loading of at least a portionof the task includes code that specifies a group of processing nodes onwhich to load one or more modules.
 14. The computer program product ofclaim 12, wherein the task comprises a plurality of modules, and whereinthe code that indicates requirements for loading of at least a portionof the task includes code that specifies at least two modules should beloaded on a single processing node.
 15. The computer program product ofclaim 1, wherein the task definition code further includes code thatindicates the task to which the task definition is associated.
 16. Acomputer data signal embodied in a carrier wave, the computer datasignal comprising: a task definition code that specifies requirements ofa task adapted to be executed on a configurable device having aplurality of processing nodes, the task definition code including: codethat indicates processing node resources required by the task.
 17. Thecomputer data signal of claim 16, wherein the task definition codefurther includes code that indicates one or more types of processingnodes required to execute at least a portion of the task.
 18. Thecomputer data signal of claim 16, wherein the task definition codefurther includes code that indicates one or more processing nodesrequired to execute at least a portion of the task.
 19. The computerdata signal of claim 16, wherein the task definition code furtherincludes code that indicates memory requirements of at least a portionof the task.
 20. The computer data signal of claim 16, wherein the taskdefinition code further includes code that indicates port requirementsof at least a portion of the task.
 21. The computer data signal of claim16, wherein the task definition code further includes code thatindicates port aliases.
 22. The computer data signal claim 16, whereinthe task definition code further includes code that indicatesrequirements for loading of at least a portion of the task onto one ormore processing nodes.
 23. A configurable device comprising: a pluralityof processing nodes; a scheduler, coupled to the plurality of processingnodes, that assigns tasks to the processing nodes for execution; and amemory, coupled to the scheduler, the memory including a task definitioncode that specifies requirements of at least one task adapted to beexecuted by the configurable device, the task definition code havingcode that indicates processing node resources required by the task.